Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Motivation and Context

Closes #1512.

Use case

Docker Compose exposes block-I/O tuning through service.blkio_config
(weights, weight-per-device, and read/write bps/iops throttles). Compose
translators such as container-compose can parse the field today, but they
must warn-skip it on apple/container because there is no runtime flag
surface for it — blkio_config: silently degrades into an unconfigured
container. This PR adds the missing surface so:

1. container-compose (and other compose translators) can pass
   service.blkio_config straight through to container run /
   container create without dropping fields.
2. Operators tuning noisy-neighbor / IO-bound workloads (databases,
   build steps, log shippers sharing a host disk) can apply BFQ-style
   weights and per-device throttles directly from the CLI, matching the
   docker run --blkio-weight* / --device-{read,write}-{bps,iops}
   ergonomics they already know.
3. The cgroup blockIO config flows through the runtime data path so a
   future podman-style translator or higher-level orchestrator gets the
   same plumbing for free.

CLI shape

Per the grouped, repeatable key=value form proposed in
#1512 (comment) (lives under MANAGEMENT OPTIONS, not
RESOURCE OPTIONS, to keep the resource help wall short):

container run --blkio weight=500 ...
container run --blkio device=/dev/sda,weight=700,leaf-weight=300 ...
container run --blkio device=/dev/sda,read-bps=1048576,write-bps=1048576 ...
container run --blkio device=/dev/sda,read-iops=1000,write-iops=1000 ...

device= accepts an absolute host path (resolved via stat(2) for
major/minor) or a literal <major>:<minor>. Per-device keys: weight,
leaf-weight, read-bps, write-bps, read-iops, write-iops. Global
keys (no device=): weight, leaf-weight. The parser rejects unknown
keys, conflicting global weights, and global-only keys mixed onto
device-less specs.

Runtime plumbing

To keep OS-specific options out of the cross-platform container config,
blockIO is carried as opaque runtime data, not on
ContainerConfiguration.Resources:

• CLI (ContainerRun / ContainerCreate) calls Parser.blockIO(specs:),
  wraps the result in LinuxRuntimeData(blockIO:), JSON-encodes it, and
  passes it as runtimeData to ContainerClient.create.
• RuntimeService.bootstrap reads RuntimeConfiguration.runtimeData
  from disk and threads it into configureContainer, which decodes
  LinuxRuntimeData and applies czConfig.blockIO (a
  Containerization.LinuxBlockIO, the Sendable wrapper around the OCI
  type).

Dependency

Depends on apple/containerization#739, which introduces
Containerization.LinuxBlockIO and wires it into
LinuxContainer.Configuration. While #739 is unmerged this branch pins
containerization to its branch
(full-chaos/containerization@feat/chaos-1380-blkio-runtime,
revision 3d009df). Before merge, the pin moves back to
apple/containerization at whatever revision lands #739.

Testing

• Tested locally
• Added/updated tests
• Added/updated docs

swift build clean, swift test --filter ParserTest passes
(105 tests, 5 new) — tests call Parser.blockIO directly now that the
field is no longer on Resources:

• testResourcesBlockIOFlags — combined global + per-device + throttle
• testResourcesBlockIOAcceptsMajorMinorLiteral — device=8:0 literal
• testResourcesRejectsInvalidBlockIOWeight — weight outside 10..1000
• testResourcesRejectsUnknownBlockIOKey — typo detection
• testResourcesRejectsGlobalKeyOnDeviceSpec — read-bps without device=

RuntimeConfigurationTests pass (runtime-data round-trip).
container run --help confirmed renders the new --blkio flag under
MANAGEMENT OPTIONS.